Programming language system for generating a program system of a real-time system on a high level language

ABSTRACT

A programming language system in a high level language should comprise language means that enable a reliable and purely logical programming of a locally transparent communication between programs sequencing parallel. This is enabled by the introduction of a specific data type, that is referred to as the service type, that combines references to components (objects) of a service to form a service interface that is announced to the operating system.

BACKGROUND OF THE INVENTION

A program system for controlling a real-time system, particularly aswitching system, should contain a communication mechanism that allows aflexible, loosely connected distribution of the functions onto thevarious processors of the real-time system. A communication mechanism isrequired for this purpose that enables two programs (a client programand a server program) running parallel for communication to be connectedto one another without specifying the correction location.

SUMMARY OF THE INVENTION

An object of the invention is to provide a programming language systemin a high level language such that a reliable and purely logicalprogramming of the communication mechanism is enabled.

This and other objects and advantages of the invention are achieved by aprogramming language system for generating a program system of areal-time system in a high level language, comprising

a) modules for modularizing the program system that comprise proceduresand data types, that are referred to as objects;

b) a specific data type, that is referred to as the service data type,that describes a communication interface that can comprise one or morereferences to the objects;

c) a declaration instruction for static generation and initialization ofan instance of the service type, what is referred to as a serviceinstance, that is statically or dynamically announced to the operatingsystem;

d) a connection instruction to the operating system for the dynamicset-up of a connection to a service, which hands over a value variablefor the acceptance of the name of the requested service as well as areturn parameter to the operating system as input parameters, areference variable, that is referred to as a communication path, underwhose reference data instance the operating system stores the objectreferences of a service instance selected by the operating system; and

e) communication instructions for the implementation of communicationsto services.

As a result of the introduction of a new data type, that is referred toas the service type, also termed service data within the programminglanguage system, the application programmer addresses the other party tothe communication on a purely logical level. The knowledge of suchaddresses as a processor number or a buffer address is thus no longernecessary for programmer.

As a result of the static initialization of the instances of the servicedata type, the later dynamic initialization of the real-time system isshortened.

When the service instances are made known to the operating system in astatic fashion, only a single connection instruction is required forrequesting a service instance for the dynamic set up of a connection toa service.

As a consequence of the new language means, the compiler can check theadherence to the following conventions at the point in time ofdevelopment:

a) An access to a service data type is possibly only with a permanentlydefined built-in procedure a (connection instruction to the operatingsystem).

b) The data type between the communication path and the data type mustbe compatible.

A further embodiment of the invention provides that the service datatype comprises a partition field for which a corresponding value can berecited in the connection instruction and that enables an unambiguousidentification of a service instance for the operating system. Thisembodiment makes it possible for the user to unambiguously provide aservice instance required in a connection instruction. The operatingsystem has no selection possibility between different service instancesgiven such a connection instruction.

A further embodiment of the invention provides that the partition fieldof a service instance can be statically seized within the framework ofthe declaration instruction. Due to the static occupation of theparticipation field, the initialization of the program system generatedwith the assistance of the programming language system is shortened inthis embodiment of the invention when bringing up the appertainingreal-time system.

A further embodiment of the invention provides that the partition fieldof a service instance can be dynamically seized by a specificinstruction and the availability range of this service instance can thusbe dynamically varied. The dynamic occupation of the participant part inthis embodiment of the invention enables a later modifiability of theparticipation field and, thus, a greater flexibility with respect to theconditions to be modified later. For example, a specific range of setscan require a greater capacity of service at a later point in time.

A further embodiment of the invention provides that the service typecomprises a version identifier field or token via which a serviceinstance tells the operating system what version the service that isaccessible via this service instance comprises. The version identifiermakes it possible to reroute the communication traffic of the softwaresequenced via messages onto a newly introduced software during operationof the real-time system and, thus, makes it possible to implement asoftware replacement during operation. This rerouting is achieved inthat those modules that are affected by the software exchange mustindicate the new version identifier in their request when setting up acommunication relationship to a server module and the operating systemthereby selects the new service instance of the new server module.

A further embodiment of the invention provides that the service typecomprises a system status field via which a service instance caninstruct the operating system to ignore certain system statuses, such asload status or operating status, in view of the implementation of thisrequest given a request of a service via this service instance. Byintroducing a system status field into a service type, this embodimentmakes it possible for the user to effect that this service is alsoimplemented by the real-time system in case of special systemconditions.

A further embodiment of the invention includes a service module that canonly export service interfaces as external objects. What the servicemodule assures is that only service interfaces are exported beyond theboundary of a service module, which can have been already checked by thecompiler at the point in time of development. This means that acommunication between services of different service modules canexclusively ensue by messages and, thus, not on the basis of mechanismshaving common data.

The service module thus represents a software unit that meets thecritical prerequisite for the exchangability during the operation of therealtime system, namely the condition of exclusive communication trafficvia messages.

Another embodiment of the invention provides that

a) one of the communication instructions for the implementation of thecommunication to a service is a remote procedure call;

b) the programming language system generates a transmission procedure inthe translation of the remote procedure call, this transmissionprocedure comprising a procedure object reference as a parameter;

c) the transmission procedure decides on the basis of the value of theprocedure object reference whether the remote procedure call is trulyremote or not remote, i.e. whether it is local;

d) the transmission procedure in case of a remote procedure call that istruly remote packages the parameters of the remote procedure call into amessage and sends the latter to the reception buffer of the appertainingremote procedure; and

e) the transmission procedure directly calls the called local procedurein case of a local remote procedure, while specifying the value of theprocedure object reference.

What this embodiment assures is that, given a local remote procedurecall, the communication with the appertaining remote procedure is notimplemented via a message, i.e. via the operating system but via a localprocedure call, this correspondingly improving the dynamics of thesystem.

BRIEF DESCRIPTION OF THE DRAWINGS

An exemplary embodiment of the invention shall be set forth in greaterdetail below with reference to the drawings.

FIG. 1 shows an onion diagram for processing platforms of a distributedcontrol system that is realized with the assistance of the inventiveprogramming language system.

FIG. 2 shows the two-fold installation of memory location for a servicevariable (service instance) in the data module of the server SPU.

FIG. 3 shows the occupation of the memory for the variable comm₋₋ pathin the data module of the client SPU.

FIG. 4 shows the structure of a program example for realizing alocation-independent communication.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A distributed system, for example a switching system, should contain acommunication mechanism with which two programs running parallel (aclient program and a server program ) can be connected for communicationwithout specifying the location. In order to be able to program thisconnection on a high level language, new language-defined objects areintroduced in CHILL (CCITT High Level Language) that enable alocation-transparent and replica-transparent addressing.

The communication mechanism shall also be referred to below as "serviceaddressing".

The entire software is subdivided into containers, namely into capsules,service modules and elementary modules.

The capsule is a closed address space and forms the container forcentral resources such as heap and timer. The content of a capsule isdefined by the specification of the service modules.

The service module is the union of elementary modules that functionallybelong together and that make one or more services available to theoverall system. The service module can be embedded off line into anydesired capsule.

An elementary module contains all data and procedures that are necessaryfor the implementation of a service.

The service module is declared on the design level and serves thepurpose of being able to relocatably construct the software. What thisessentially means is that interfaces between service modules are onlyallowed to be dynamically constructed and only communication facilitiesare allowed to be activated, i.e. no direct data accesses and procedurecalls are possible.

The user declares service types in the server service module that are anabstract data mode, that are composed of sets of interface objects suchas buffer and remote procedures and that syntactically denote theinterfaces of a service.

In order to assist enhancement and location transparency, the objectsand rules for a communication in a distributed system are allocated to ahigher-ranking instance. For this reason, the objects are embedded intothe language CHILL for the setup of a communication. The compiler makesstructures available in order to be able to define these new objects inCHILL and checks the adherence to the application rules. Rules exist forthe setup and after the setup of a communication path.

The objects for setting up a communication path are called "services" inthe new CHILL. These services contain UBIs (Unique Buffer Identifiers)of buffers for asynchronous communication and remote procedures forsynchronous communication (see the later CHILL language description).

A table about all services in the system a (global service table) arisesdue to the embedding into the language system. An unambiguous number a(service identifier) is assigned for every service by the systemconstructor or (configuration system) and this is employed later on lineas an index.

The following advantages derive as a result of the recited means:

1. The compiler can have already checked adherence to the followingconventions at the point in time of development:

a) Only services are allowed to be exported and imported ascommunication interfaces.

b) The accesses to services is only possible with permanently definedbuilt-in procedures.

c) The mode compatibility between a communication path and a service islikewise checked.

d) Upon activation of the service, the compiler checks the modecompatibility of the interfaces to the server. Given asynchronouscommunication: the mode of the message and the mode of the receptionbuffer elements are checked.

Given synchronous communication: the modes of the parameters arechecked.

2. Due to the introduction of the services in the language system, theuser addresses the other party to the communication a high levellanguage in that the programmer uses service names. The compiler thenforms corresponding service identifiers from the service names. Theoperating system ultimately knows the service identifiers and the realaddresses such as, for example, a processor number or a buffer address.

3. The compiler prepares the global service table at the point in timeof the production and defines the memory area for the communicationpaths as UBI tables.

FIG. 1 shows an onion diagram for processing platforms of a distributedcontrol system that is realized with the assistance of the inventiveprogramming language system. The onion diagram comprises the followingshells:

a first shell that corresponds to the hardware of the three processingplatforms under consideration,

a second shell that corresponds to the firm wear such as the (initialprogram loader, hardware interface, error recognition, etc.) of theprocessing platform,

a third shell that corresponds to the operating system software the(operating system core, and error handling),

a fourth shell that corresponds to the base software the (data base,overload control, etc.) of the processing platform and that comprises aplurality of software units, that are referred to as capsules,

a fifth shell that corresponds to the system software the (recoverysoftware, etc) of the processing platform and that likewise comprises aplurality of capsules,

a sixth shell that corresponds to the user software the (switchingtechnology, user interface, protocol sequencing, etc.) of the processingplatform and that likewise comprises a plurality of capsules.

Only the software sequencing above the second shell is combined inservice modules SPU and in capsules. The shells 1-3 together representthe basic processing platform and are the same for every processingplatform type.

CHILL (CCITT (International Telegraphic and Telephone ConsultiveCommittee) High Level Language) is a modular programming language with astrict type concept. CHILL programs are divided into modules thatexchange objects with GRANT ("export") and SEIZE ("import") commands.These modules are also referred to below as elementary modules.

A system of modules can be combined to form what is referred to as aservice module a ("service provisioning unit"). The service module thenrepresents a visibility limit for all identifiers granted by thecombined modules. Service modules form a relatively self-containedsoftware system; they always belong complete to a closed address space.

Service modules also exchange objects with GRANT and SEIZE commands.Whereas, however, ordinary CHILL modules can nearly all export andimport objects defined on a global level (for example, variables,procedures, constants and modes), service modules are only allowed toexport/import scaler constants, modes (types) and services.

"Services", which shall also be referred to below as service instances,serve the purpose of combing certain services and information(procedures and data) and of making then known to the operating systemOS, to a global service manager of the operating system, to be moreprecise. When a service module makes a certain service available via aservice instance that another SPU requires, then a request is made tothe service manager dynamically at the running time that the servicemanager satisfies from the providers that he has.

The presentation of service instances in the programming language CHILLshall be set forth later.

The classic communication between two software units occurs in theswitching software via the sending of messages to message buffers. Suchbuffers, which can accept messages, are defined with the keyword BUFFERin CHILL.

In classic buffer communication, the address of the receiving buffermust be known for transmitting. So that messages can also be exchangedbetween buffers that do not lie in the same address space, however, in adistributed system, what are referred to as "remote references" must bedefined, these communicating with one another with specific supervisorcalls.

In CHILL, a remote reference is defined with

    <bound remote reference mode>:=REF <>REMOTE.sub.-- REFERENCE<><buffer mode>

A remote reference variable is then declared with

DCL <name><bound remote reference mode>;

With the assistance of the operating system, a buffer address iscompleted to form a UBI (unique buffer identifier) and is stored in sucha remote reference location.

There can be procedures within the modules of a service module whoseservices are also required by other SPUs. In order to make theseservices known to the outside, the procedure cannot be granted from theservice module (that is forbidden) but must first be specificallyidentified:

    <name>: PROC (  <formal parameter list>!) <>REMOTE.sub.-- PROCEDURE<>;

This procedure must then be embedded into a service that can be grantedto other service modules.

A remote procedure mode is a formal type that has the same propertiesand parameters as a corresponding procedure.

In the CHILL sense, a service is a variable an (instance) declared onthe SPU level with the DCL ("DeCLare") command. The mode or (type) ofthis variable, which is referenced below as service mode or servicetype, is either seized by another SPU or is defined in an elementarymodule of the current SPU.

Service modes are defined via a CHILL-STRUCT mode and are specificallyidentified by a compiler directive.

The component modes of a service mode contain management information forthe OS and the actual "services", namely remote reference modes andremote procedure modes.

The syntax of the service mode in CHILL follows:

    ______________________________________                                        <composite mode> ::= <service mode>                                           <service mode> ::=                                                            STRUCT (                                                                              <partition field>                                                                             ,                                                             <service attribute field>                                                                     ,                                                             <service field list>                                                                          )                                                                    <>SERVICE<>                                                    <partition field> ::=                                                         <field id> { <set mode> .linevert split. <range mode> }                       <service attribute field> ::= <fixed field>                                   <service field list> ::=                                                      <service field>                                                               .         { , <service field> }*                                              <service field> ::=                                                           <field id>                                                                    { <remote procedure mode name>                                                 .linevert split. <remote reference mode name>                                 .linevert split. RBF <>REMOTE.sub.-- REFERENCE<> <buffer mode name>}         <service declaration> ::=                                                     <defining occurrence list> <service mode name>                                INIT := (:                                                                            <constant value>,                                                              <reference value list>                                                          :)                                                                 <reference value list> ::=                                                    <reference value>                                                             { , <reference value> }*                                                      <reference value> ::=                                                         <remote procedure name> .linevert split. ADDR ( <buffer                       ______________________________________                                        name> )                                                                   

The semantics of the syntax of the service mode shall be set forth ingreater detail below.

The first field of the service mode is the partition field and servesfor OS (operating system) management. Its mode must be SET or RANGE ofINT; which is employed by the OS for the identification of the service.

The second field, that is referred to as the system status field, alsoserves the purpose of OS management. Its mode is a specific powersetmode; it informs the OS what system statuses are to be ignored whenlaying claim to this service instance.

Thereafter, an arbitrary plurality of service components (but at leastone service component) can be specified by the mode remote procedure orremote reference.

The declaration of the service variables is implemented via a DCLstatement, followed by a static INIT (initialization). This staticinitialization is the single possibility of allocating the components ofa service to procedures or buffers. An allocation to service componentsis not allowed; service variables are only allowed to be employed in SVC(supervisory call) calls.

The procedures and buffers that are allocated to the service in thestatic INIT must have been defined in elementary modules of the sameservice module.

A service instance an (initialized service variable) is made known tothe operating system either statically (i.e. at the time of reduction ofthe real-time system) or dynamically (i.e., at the running time of thereal-time system).

Whereas the static disclosure is implemented by the configurationsystem, the dynamic disclosure ensues on the basis of an explicitinstruction an (announce instruction) to the operating system. Thedynamic announcing, moreover, is expressed in the initialization of aservice instance in that the partition field is initialized only with adummy.

A code example of that stated in CHILL shall follow later.

A dynamically announced service can be reported as being no longeravailable ("withdrawn") when, for example, the corresponding serverleaves the network.

The dynamic announcing and withdrawing is realized in CHILL via twobuilt-in routines that directly branch into the OS and have thefollowing syntax:

    ______________________________________                                        <announce service built-in routine call> ::=                                           ANNOUNCE.sub.-- SERVICE (                                                         <service name> ,                                                              <partition value> );                                             <withdraw service built-in routine call> ::=                                           WITHDRAW.sub.-- SERVICE (                                                         <service name> ,                                                              <partition value> );                                             ______________________________________                                    

The connection instruction "CONNECT₋₋ SERVICE" shall be set forth ingreater detail below.

When a client requires a specific service, the client must set up whatis referred to as a communication path between himself and the server.This server is identified via the partition ID. With reference to thepartition ID, the service manager seeks an available server and sets upthe connection.

    ______________________________________                                        <connect service built in routine call> ::=                                   CONNECT.sub.-- SERVICE (                                                                 <communication path>                                                                          ,                                                             <service id>    ,                                                             <unit>          ,                                                             <partition.     ,  !                                                          <token>         ) ;                                                <communication path> ::= <reference variable name>                            <unit> ::= <unit value>                                                       <partition> ::= <partition value>                                             <token> ::= <token value>                                                     ______________________________________                                    

The most important parameter is thereby the <communication path>.Formally, its mode is a REF SERVICE₋₋ MODE. Memory is reserved for it inthe data module of the client into which the service manager writes theUBIs/remote procedures of the requested services.

After a CONNECT₋₋ SERVICE, the components of the service are known tothe client. He can then access this via the <communication path>and callin the remote procedures or send messages to the UBIs.

The syntax of a call from CONNECT₋₋ SERVICE as well as the subsequentcall of a remote procedure (PROC1) and of a sending of a message (usingthe CAST command) are set forth below.

    ______________________________________                                        L.sub.-- RESULT := CONNECT.sub.-- SERVICE ( COMM.sub.-- PATH,                                   SERVICE.sub.-- VAR,                                                           ONSMV01.sub.-- ANY.sub.-- GP,                                                 ID.sub.-- 2, /* Partition */                                                  TOKEN  );                                                   IF L.sub.-- RESULT = SUCCESS.sub.-- OK                                        THEN                                                                          DO WITH COMM.sub.-- PATH->;                                                   PROC1 (1, C);       /* call remote proc. */                                          ON ( BUFF.sub.-- OVERFLOW) : ;                                                ELSE;                                                                         END;                                                                   L.sub.-- SUCCESS := CAST ( UBI.sub.-- 1,  /* cast message to ubi */                    L.sub.-- CALL.sub.-- MESSAGE );                                      OD;                                                                           FI;                                                                           ______________________________________                                    

So that these remote procedure calls function, some additional code muststill be generated in the compiler in order to supply the necessarysupport. This is set forth in greater detail below.

As already explained, remote procedures are procedures that a servicemodule can include in a service and that can be employed by otherservice modules in this way, i.e. "can be called".

The language means visible for the user convey the impression that whatis hereby really involved is a call in the traditional sense. Since,however, services can also be exported into other address spaces, it isclear that a remote procedure call (referred to as RPC below) cannot bea matter of a traditional procedure call in the classic sense. On thecontrary, the compiler must generate additional code in the definitionof a remote procedure and in the call of a remote procedure component.

Remote procedure calls are realized via a generated CAST ("transmit")and RECEIVE sequence. By contrast to traditional calls, namely, it ispossible to send messages to buffers across SPU boundaries and evenacross address space boundaries via the supervisory call (SVC) "CAST"and the language means "remote reference", since remote referencesdefine unambiguous buffers Ids system-wide. This is used for remoteprocedure calls; what thus looks like a normal procedure call for theuser is in reality a sending of messages.

Since every remote procedure can be potentially embedded into a serviceand can be employed (called) from the outside, a buffer (the "stubbuffer") is required for it, the stub buffer receiving the messages thatcome from the remote callers. This buffer is implicitly created by thecompiler in the definition of a remote procedure.

Further, a process is implicitly generated (the "incoming stub process")that reads this buffer out and calls the procedure as soon as a messagearrives. This process lies in the same SPU as the remote procedure andcan thus call the procedure.

The buffers and remote procedures are announced to the compiler in thestatic INIT within the declaration instruction DCL of a servicevariable, namely those that the service should contain. They derive fromelementary modules of the same service module.

The compiler thus creates memory location for every service declarationin the data module of a service module in order to deposit the addressesof the buffers and remote procedures there. The principal information iscomposed of link control instructions, i.e. information to the linkerabout the buffers and procedures to be entered here.

The compiler must thereby offer the following information:

1. If the service true "remote" is employed, the service variable andthe data module must offer information about all buffers employed viaADDR (buffer). the appertaining stub buffer is entered at this locationfor all remote procedures employed. The connection stub buffer <->remote procedure is thus set up.

2. For optimization reasons, is must also be possible to directly employRPCs (remote procedure calls). When, namely, the service request comesfrom the same address space (and the address of the remote procedure isvalid), then the procedure can be directly called; the detour viaCAST/RECEIVE functions with the assistance of the stub buffer is notnecessary. For this purpose, the store size of the service is laid up asecond time in the SPU data module. The addresses for the remoteprocedures are directly entered here.

FIG. 2 shows the information deposited in the data module of the serverSPU for the two cases cited above.

The linker reads these information deposited in the data module, entersthe absolute addresses, and enters these service variables into itsservice table. This linker service table is then completed by the online and off line builder and is made available to the service manageras a global service table (GST).

What is referred to as a communication path is required in order toprogram a CONNECT₋₋ SERVICE. Formally, this is a variable of the modeREF SERVICE₋₋ MODE. In this declaration, the compiler reserves memory inthe data module.

FIG. 3 shows the occupation of the memory for the variable comm₋₋ pathin the data module of the client SPU. The abbreviation "RP" therebydenotes "address of the remote procedure".

The service manager makes the decision whether an optimized or remoteservice request is present.

After the CONNECT₋₋ SERVICE, the UBIs or remote procedures of theservice in the data module of the user are available for the usersoftware. Via

    communication.sub.-- path->. component

The user can access the service components, i.e. can code a CAST to theUBIs or call the remote procedures (remote procedure call RPC).

Such RPCs coded in the user source cause the compiler to generate animplicit procedure (one for each RPC) that receives the parameters ofthe RPC and the communication path as parameters. This procedure iscalled an outgoing stub. A response buffer is also created in additionto it.

Precisely this outgoing stub is first called in every RPC, in that adecision as to whether the call is remote or not is made on the basis ofthe information in the communication path.

In the optimized case, the communication path directly contains theprocedure address; the procedure is directly called.

In the remote case, the stub packages the RP (remote procedure)parameters into a message (together with the UBI of its own responsebuffer, quasi its "sender") and sends this to the stub buffer of theremote procedure (whose UBI is in the communication path).

When the response message arrives, the result of the sending operatingis returned to the caller together with the result parameters.

The sequences that have been set forth shall be summarized again belowand illustrated with reference to an example in CHILL source code.

As already set forth in greater detail, the following steps are runthrough for the service addressing:

1. The server declares buffer or programs remote procedures; for thelatter, the compiler creates an incoming stub process and a stub buffer.

2. A service is declared in the service module of the server. Thebuffers, stub buffers and procedure addresses contained therein arewritten into the SPU-T module and are accepted into the global servicetable by the linker/builder.

3. The service is announced.

4. The service is seized in the client SPU and a communication path thataccepts the service components is defined.

5. The user of the service calls the CONNECT₋₋ SERVICE. The servicemanager thereby enters the UBIs/RP addresses into the communicationpath, dependent on whether the optimized service or true "remote" isemployed.

6. The user casts a message to a UBI component or calls an RP component.In RPC, the appertaining outgoing stub generated by the compiler iscalled.

7. The outgoing stub decides on the basis of a flag in the communicationpath whether the procedure is to be directly called or whether an RPC₋₋CAST is to be implemented.

8. In the remote case, the parameters given to the stub are alsopackaged into a message for the remote procedure and are sent to the UBIof the stub buffer of the remote procedure with RPC₋₋ CAST.

9. The incoming stub process (that waits for CASTs at the stub buffer)receives the message from the stub buffer, reads the parameters out anddirectly calls the procedure.

10. After the conclusion of the procedure, the stub process packages theresult parameters into a message and returns this to the callingoutgoing stub.

11. The outgoing stub receives the result message, reads the parametersout and forwards them to its caller.

FIG. 4 briefly illustrates an example of the service addressingpresented below in the CHILL code. The abbreviation "OS" occurring inthe CHILL example thereby means "operating system".

The code for a service module requesting a service (client SPU) followsfirst, as well as the CHILL-wise presentation of that code that isautomatically generated by the compiler. ##SPC1##

Although other modifications and changes may be suggested by thoseskilled in the art, it is the intention of the inventors to embodywithin the patent warranted hereon all changes and modifications asreasonably and properly come within the scope of their contribution tothe art.

We claim:
 1. In a computer, a programming language system for generatinga program system of a real-time computer system on a high levellanguage, comprising:a) modules for modularizing the program system thatcomprise procedures and data types that are objects; b) a specific datatype being a service type that describes a communication interface thatcomprises at least one reference to said objects; c) a declarationinstruction for static generation and initialization of an instance ofthe service type that is a service instance, that is announced to anoperating system to be implemented on computer hardware; d) a connectioninstruction to the operating system for the dynamic set-up of aconnection to a service, which hands over a value variable for theacceptance of the name of the requested service as well as a returnparameter to the operating system as input parameters, a referencevariable that is a communication path under whose reference datainstance the operating system stores said at least one reference to saidobject of a service instance selected by the operating system; e)communication instructions for implementation of communications toservices.
 2. A programming language system according to claim 1, whereinsaid service type comprises a version identifier field via which aservice instance tells the operating system for implementation on acomputer what version of service accessible via said service instancecomprises.
 3. A programming language system according to claim 1,wherein said service type comprises a system status field via which aservice instance instructs the operating system for implemenation on acomputer to ignore certain system statuses in view of implementation ofa request given a request of a service via said service instance.
 4. Aprogramming language system according to claim 1, further comprising: aservice module that only exports service interfaces as external objects.5. A programming language system according to claim 1, furthercomprising:a) one of the communication instructions for implementationof the communication to a service is a remote procedure call; b) theprogramming language system generates a transmission procedure in atranslation of the remote procedure call, said transmission procedurecomprising a procedure object reference as a parameter; c) thetransmission procedure decides on a basis of a value of said procedureobject reference whether the remote procedure call is truly remote ornot remote; d) the transmission procedure in case of a remote procedurecall that is truly remote packages the parameters of the remoteprocedure call into a message and sends the message to a receptionbuffer of an appertaining remote procedure; e) the transmissionprocedure directly calls a called local procedure in case of a localremote procedure, while specifying a value of the procedure objectreference.
 6. In a computer system, a programming language system forgenerating a program system of a real-time computer system on a highlevel language, comprising:a) modules for modularizing the programsystem that comprise procedures and data types that are objects; b) aspecific data type being a service type that describes a communicationinterface that comprises at least one reference to said objects; c) adeclaration instruction for static generation and initialization of aninstance of the service type that is a service instance, that isannounced to an operating system to be implemented on computer hardware;d) a connection instruction to the operating system for the dynamicset-up of a connection to a service, which hands over a value variablefor the acceptance of the name of the requested service as well as areturn parameter to the operating system as input parameters, areference variable that is a communication path under whose referencedata instance the operating system stores said at least one reference tosaid object of a service instance selected by the operating system; e)communication instructions for implementation of communications toservices, wherein said service type comprises a partition field forwhich a corresponding value is recited in the connection instruction andthat enables an unambiguous identification of a service instance for theoperating system.
 7. A programming language system according to claim 6,wherein said partition field of a service instance is statically seizedwithin a framework of the declaration instruction in a computer system.8. A programming language system according to claim 7, wherein saidpartition field of a service instance is dynamically seized by aspecific instruction in a computer system and an availability range ofsaid service instance is dynamically varied. A programming languagesystem in a high level language should comprise language means thatenable a reliable and purely logical programming of a locallytransparent communication between programs sequencing parallel. This isenabled by the introduction of a specific data type, that is referred toas the service type, that combines references to components (objects) ofa service to form a service interface that is announced to the operatingsystem.
 9. A computer-implemented method for generating a program systemof a real-time computer system on a high level language, comprising thesteps of:providing modules for modularizing the program system thatcomprise procedures and data types that are objects; describing acommunication interface as a specific data type which is a service typeincluding at least one reference to said objects; announcing to anoperating system to be implemented on computer hardware a declarationinstruction for static generation and initialization of an instance ofthe service type which is a service instance; providing a connectioninstruction to the operating system for dynamic set-up of a connectionto a service, said connection instruction handing over a value variablefor acceptance of the name of the requested service as well as a returnparameter to the operating system as input parameters; selecting areference variable that is a communication path under whose referencedata instance the operating system stores said at least one reference tosaid object of a service instance by the operating system; and providingcommunication instructions for implementation of communications toservices.
 10. A method as claimed in claim 9, further comprising thesteps of:providing a remote procedure call as one of the communicationinstructions for implementation of the communication to a service;generating a transmission procedure in a translation of the remoteprocedure call in the programming language system, said transmissionprocedure being a procedure object reference as a parameter; decidingthe transmission procedure on a basis of a value of said procedureobject reference whether the remote procedure call is truly remote ornot remote; packaging the parameters of the remote procedure call into amessage and sending the message to a reception buffer of an appertainingremote procedure in case of a remote procedure call that is trulyremote; directly calling a called local procedure in case of a localremote procedure, while specifying a value of the procedure objectreference.